home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 6 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB

  1. Path: digex.net!not-for-mail
  2. From: jdc@access2.digex.net (John Cochran)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Circular buffering for FILEs?  Why not?
  5. Date: 1 Jan 1996 18:20:46 -0500
  6. Organization: Express Access Online Communications, Greenbelt, MD USA
  7. Message-ID: <4c9q8e$63i@access2.digex.net>
  8. References: <4c9i65$3b6@segfault.monkeys.com>
  9. NNTP-Posting-Host: access2.digex.net
  10.  
  11. In article <4c9i65$3b6@segfault.monkeys.com>,
  12. Ronald F. Guilmette <rfg@monkeys.com> wrote:
  13. >I have a question about the traditional implementation of buffered FILEs.
  14. >
  15. >(My apologies to readers of comp.std.c.  I know this isn't a question
  16. >which relates directly to the text of the C standard, but I do need to
  17. >put the question to people who are well versed in the details of C imple-
  18. >mentations, and comp.std.c is one likely place to find such people.)
  19. >
  20. >Traditional implementations of getc and putc look pretty much as follows:
  21. >
  22. >----------------------------------------------------------------------------
  23. >#define getc(p)         (--(p)->_cnt < 0 ? __filbuf(p) : (int)*(p)->_ptr++)
  24. >#define putc(x, p)      (--(p)->_cnt < 0 ? __flsbuf((unsigned char) (x), (p)) \
  25. >                                : (int)(*(p)->_ptr++ = (x)))
  26. >----------------------------------------------------------------------------
  27. >
  28. >The important point to note here is each of these macros causes the
  29. >``file pointer'' (_ptr) to be incremented... in a very simple-minded
  30. >fashion... whenever a character is taken from, or added to the FILE's
  31. >buffer (respectively).
  32. >
  33. >From this fact I deduce that traditional implementations of the entire
  34. >stdio set of functions _do not_ treat FILE buffers as so-called ``circular
  35. >buffers'' but rather treat them a mere linear buffers.
  36. >
  37. >My question is just this... Why?
  38. >
  39. >Given that traditional implementations of the FILE structure include a
  40. >``_cnt'' field, it seems to me that it would have been possible... albeit
  41. >at a slight cost... to treat FILE buffers as circular buffers, wraping
  42. >the value of _ptr back to the physical beginning of the buffer each time
  43. >it was seen to have passed the physical end of the buffer.  But it seems
  44. >that nobody does this.  Why not?
  45.  
  46. Why bother?
  47.  
  48. The purpose of a buffered file is to improve performance by reducing the number
  49. of physical I/O operations.
  50.  
  51. Lets look at the 2 major cases, input and output.
  52.  
  53. If the buffered file is used for input. You first fill the buffer.  Then as
  54. long as the buffer isn't empty, you return bytes from the buffer.  When the
  55. buffer finally empties, you fill it again.  Notice that you never perform a
  56. physical I/O on the buffer unless it is empty.  Implimenting the buffer as
  57. a circular buffer wouldn't improve performance and would just make it more
  58. complex.
  59.  
  60. Now if the file is being used for output.  You start with an empty buffer.  You
  61. proceed to fill the buffer.  When ever the buffer fills, you flush it to the
  62. physical device. Once again, the only physical operation is to flush the entire
  63. contents of the buffer.  When you write anything from the buffer, you write the
  64. entire contents of the buffer.  So a circular buffer wouldn't gain you anything
  65. except more complexity.
  66.  
  67. Hope this helps.
  68.  
  69.